過去我曾經在其他文章及我出版的書中解釋過 GitLab 的使用者權限。

GitLab 的權限控管會由以下四個項目構成：
User 的 Access Level。
User 是否為特定 Project 或 Group 的 Member。
User 在 Project 及 Group 是哪一種 Member Permissions Roles。
Project 及 Group 的 Visibility Level 為何。
（Member Permissions，修正為 Roles ）

其中最關鍵的，就是 User 在 Project 或 Group 的 Roles。

GitLab 預設了 6 種 Roles 讓我們使用

• Guest
• Reporter
• Developer
• Maintainer
• Owner
• Minimal Access（這個非一般使用情境，有機會再跟大家解釋）

在一般的情況，原廠預設的這些 Roles 已足夠因應大部分的使用情境。但就如我在 Day 3 提到的，當你的使用情境進入到有規模的企業時，各種天馬行空的權限需求就會一一浮現。在這樣狀況下，預設的 6 種 Roles 就無法有效的滿足需求；舉例來說，在大企業可能會需要一種介於 Reporter 與 Developer 之間特別的 Role，因為除了開發團隊，其他像是資安團隊也會需要進來幫忙 Review 程式碼，但資安團隊又不希望自己去介入到程式開發。（資安團隊：我們除了要看到資安掃描的報告，也可以順便看一下程式碼，但你不要開可以 Commit 的權限給我，Code 你們要自己改喔～）

針對這種需要細微調配 User Permissions 的需求，就是付費功能 Custom roles 登場的時刻！

在 GitLab 最高的付費等級 Ultimate，提供了名為 Custom roles 的功能，讓管理者可以自訂出新的 Roles，以原廠預設的 Base Roles 為基礎，再去附加其他的權限上去。

因此在上面的情境中，主事者就可以新創建一個名為「Security reviewer」的 Role，先以 Reporter 為基礎，再賦予它可以查看 Vulnerability reports 和 Security dashboards 的權限；因為 Reporter 本來就有程式碼的 Read 權限，接著又附加了 Developer 以上才能查看 Vulnerability reports 的權限，如此一來就能滿足前面舉例的資安團隊權限需求。

目前 Custom roles 能夠附加的 Permissions 有限，自由度也尚未達到所有 GitLab 功能的權限皆可任意自由配的程度，因此如果你真的有特別奇怪的權限需求，還是先諮詢一下原廠，確認是否可以達成。

我個人是覺得，這個功能應該要下放到 Premium 付費等級，並且要開發可以做到更多樣的權限自由配對，這樣會更有吸引力！

圖片來源 - 吉卜力工作室 https://www.ghibli.jp/works/majo/#&gid=1&pid=34